Supporting Cross-Application Contexts with Dynamic User Interface Fusion

Currently, user interfaces are defined by single applications but workflows may span multiple ones. In the result, users have to work with separated programs in parallel and deal with separated interfaces to fulfill their tasks. In desktop computing with extensive screens, working with several opened windows might not be eligible but bearable. For mobile devices with very restricted interaction capabilities (e. g. scarce screen estate), the limitations of traditional UIs become a barrier. Therefore we argue that not applications but workflows and tasks should be the determinant for the user interface. This paper introduces in the research question about how to identify the user’s current task and focuses on how to reorganize user interfaces across multiple concurrently used applications. 1 Motivation and Introduction When using desktop computers or ubiquitous devices like PDAs, features required to complete a given task usually span across different applications. In ubiquitous computing scenarios, display resources and user interaction options are typically very limited. Current mobile operating systems tend to display only the user interface of the application in focus, hiding other applications which might be relevant to the current workflow. In our recent publication [BK07], we call this behavior greedy screen allocation. Greedy screen allocation disrupts the user’s perception of information and actions relevant to her working context. In order to find the hidden information again, the user is forced to switch to another application, loosing the user interface of the first application out of sight. Lack of orientation and a decreasing productivity might be the consequences. Therefore we argue that not the predefined interface of an application should define the UI view but workflows and tasks should be the determinant for user interfaces. The first arising question is: how can we identify the user’s current tasks and workflows? Since this is out of focus of this paper, we assume the working context to be available in form of an aggregated sensor.1 1Such a sensor will take several basic context data into account, like calendar entries, interaction history, running programs, existing indexed documents, accessible devices e. g. printers, incoming or currently open phone calls, etc.